WhatIf DSViewer

The Widget Layout.

The layout of the widget is fairly simple and only has 2 major sections with subsequent subsections.

The first major section of the widget is the Control Panel on the top left. On this control panel you can switch between branches, switch between stores, commit modifications to the current store, or reset your current workplace. 

The second major section of the widget is the Workplace. The workplace is where you can visualize your changes and collect snapshots of the Datastores. Each table is switchable via the tab subsection. The tables that are currently available in the widget are Query Results, Adding, Changing and Removing.

Each table in the workplace has its own custom cell editors, row actions and header actions to help you manipulate your data in the table. There are also buttons associated with each table that help you manipulate all your tables' content.

Operating the Control Panel

Loading/Committing Data

Loading Data

It is important to note that, besides the initial store names and store headers, all data is manually loaded by the users command. The button "Load" found in the Query Results tab needs to be pressed for any Datastore content to be loaded into your workplace. This is an intentional design, as the user might need to set some criteria and filters to reduce how much data is loaded. 

The criteria that are used to load data are based on the following parameters that can be set by the user:

• MaxRows
• Store Name
• Branch Name
• Filters (datastore conditions)
• Fields Removed

It is recommended to not load the entire Datastore at once and only load the data you wish to manipulate based on your necessary criteria.

Loading data from the Datastore will only make changes to the Query Results table and will not affect your Create, Update or Delete tables. Rows copied from the Query Results table to any other table will stay there regardless of whether that same row currently exists in the Query Results table.

Committing

Once a user has all of their row additions, row removals and row changes ready, then they can commit their workplace to affect the datastore by clicking the "Commit" button. This button will only be enabled if any additions, removals and changes are present in one of the 3 tables. After clicking the "Commit" button, since this is making changes on the server side, a warning for the action will popup asking users if they want to continue with the action.

If a table has any row to commit, then the WhatIf DSViewer service on the backend will generate a definition for that table to apply the commit. There are a maximum of three definitions for each WhatIf DSViewer submission and each definition will take effect in the following order: 

1. Adding Definition
2. Changing Definition
3. Removing Definition

Various restrictions are in place in the widget to make sure changes made in one definition do not get overwritten by changes made to another definition (for example, preventing "Changes Table" and "Removing Table" from having the same rows).

Upon success of a commit, then all tables will be automatically reset. This includes the Query Results table as it might have stale data that needs to be reloaded.

If a commit causes a WhatIf DSViewer service failure to be thrown, then a popup will be displayed indicating that the server could not complete the action and no reset will be triggered for the tables. 

Control Panel Criteria Setting

Managing Branches

Managing branches on this widget is handled on the control panel on the top left.

Here you can find the branch dropdown and the "Create Branch" button.
Please note that for this widget you do not actually create a new branch in AP until you commit your workplace with the commit button in the "Actions" subsection.

Switching Between Branches:

When you open the widget for the first time, the widget will ping the FRTB server for any existing branches on the Datastore. For all branches that exist, the dropdown will be populated with them, further allowing users to switch between them.

When a user selects a particular branch, nothing is loaded yet. Instead, because branches could have stale or different data to one another, a workplace-wide table reset is enforced by the widget.

Creating Branches:

The "Create Branch" button is the "Commit As.." button. By clicking this button, a user can create a brand new branch in the Datastore, regardless of whether they are making any updates, creations or deletions to the Datastore. As with the "Commit" button, since this performs a server side change, a warning for the action will popup. This button will only be enabled when on the master branch. Any new branch created with this button will be branched off the Datastore's master.

Managing Stores

When you open the widget for the first time, it will ping the FRTB server and collect all the store descriptions needed to populate the store name dropdown. From this dropdown (on the control panel) the user can switch between stores.

As with the branch dropdown when a user selects a particular store, nothing is loaded yet. Instead, because stores will probably have different fields, a workplace-wide table reset is enforced by the widget.

Setting MaxRows

The number of rows that are loaded will not exceed the number defined in the MaxRows section of the control panel. By default this parameter is set to 100, but can be manipulated to any integer number. If a non-integer value is provided, then this will result in an empty table being loaded.

Resetting Tables

Each table will have its own reset button to conveniently reset all table changes or snapshots loaded by the user for their respective table. In the control panel there is also a "Reset All" button used to do the same, but for all tables across the workplace.

Operating the Workplace

The Tab Section

The workplace contains multiple tables each with its own behaviors and purposes for manipulating the Datastores. To manage these tables, you can use the tabs section to switch between tables. Currently the four tables you can switch between are Query Results, Adding, Changing and Removing.

To switch between the tabs, simply click on the name of the table you wish to go to. The default tab is "Query Results" and this will be the first table you will focus on when the widget initializes.

The Query Results Table

The Query Results Table is the table that is used (after clicking on the load button) to get a small "snapshot" based on the criteria previously defined. Snapshots in this table do not automatically update and can become stale over time.

The Query Results Table can be brought up with the first tab in the tab selection.

Header Manipulation

Some header-specific criteria can be defined for the query results before loading the data from a Datastore. These include filtering data for each field name and removing fields to load entirely.

To completely remove a specific field from being loaded from the Datastore the user can right-click on the field in the table's header and use the "Remove Header(s)" action. As the name implies, if the user has selected multiple headers he/she can remove all of them at once. This action will not work for primary key fields and in fact will be disabled if the user has selected a primary key field to be removed. When the header action is disabled, the action will be renamed to "Cannot Remove Primary Fields." 

Besides removing headers the "Filter" button will bring up a popup to help the user set conditions for each field if they wish. These conditions will be used to filter rows that fail to meet the conditions for each field. 

Filtering Popup 

When the user brings up the filtering popup, which can be done by clicking on the filter button above the query results table, the user can set conditions for each field to filter on when data is loded. Any active filters that currently exist on the table will be shown in the popup when it is brought up (if the user already defined a condition for field "Example_A" then, when the filter popup comes up, the same condition value will be set for "Example_A.")

When the user has finished setting conditions for each field and clicks the "submit" button of the popup then the filters will show in the headers of the query results table. Each field with a filter will have a string showing ": xxxx" appended to it, where xxxx represents the value for the condition applied. 

To understand more about conditions and how they work in datastore queries please refer to the ICondition documentation here: https://support.activeviam.com/confluence/display/COMP/ICondition

NOTE: Because setting filters can be time consuming and complex (depending on how complex the user wants his/her conditions to be), resetting the query results table will NOT reset filters. This is to prevent the users from losing complex filtering logic they may have set and want to lock. To remove filters the user will have to simply pull up the filter popup again and delete them manually. 

Non-Numeric Filtering:

For non-numeric fields the filter popup will have a label and text field to fill in. The text field will either be ignored if it is blank, or if set to some value it will be used to add a Datastore "like" condition on that field. A datastore "like" condition will verify true or false after two steps for each field. These include:

1. Call the field values "toString()" to get the string representation for the data.
2. Use the value provided as a regular expression and verify if the regex expression matched.

If steps 1 or 2 fail then the "like" condition fails overall. Its unlikely for step 1 to fail however as data in the datastore should be represented as instantiated object types and not nulls.

Under the hood the regex used for the like condition is implemented by Java's Pattern library. This library supports the standard regex operators such as match-any (.), match-zero-or-more (*), anchors (^), and more.

Numeric Filtering:

For numeric fields (Double, float, Integer, etc) the field will have an additional dropdown to select from multiple filtering options. These options are those that work and make sense for numeric types of data. They include:

• equals-to (eq)
• greater-then (gt)
• greater-then-and-equals-to (gte)
• less-then (lt)
• less-then-and-equals-to (lte)

These condition types should be self-explanatory and work as expected when both the data in the Datastore and the value matched against are both numeric. Technically the above condition types will also work for any objects types as long as they implement the comparable interface, but for the DSViewer widget only numeric type fields are allowed to use them.

When displayed in the Query Results headers, after submitting the numeric conditions, then both the value of the condition and the type of the condition will be displayed in the header (ex: "Example_B: {eq: "14"})

Row Actions

Users cannot manipulate the data in the Query Results table. Instead, users can move rows they wish to remove or manipulate to other tables via the row actions to the far right of the table.

The two row actions currently available are "copy to the changing table" represented by a black pencil icon and "copy to the removing table" represented by a black X icon. Copying a row to the changing or removing table locks it there based on its primary keys and can not be done twice. If the user already copied a row from the query results table to the changing table, for example, and tried to add it again to the changing table or add it to the removing table, the action will be ignored. Snackbars with warnings and confirmations for the actions will popup, to indicate the action was either successful or not. If not, the popup will give a warning for why the action was invalid.

The Create Table

If the user desires to add new rows to a Datastore, he/she can add their new rows in the "Adding Table". The button "Add" above the table will create a new blanked-out row which the user can edit by left clicking on the cells of the table.

Any cell in the add table is modifiable if the user double-clicks on it. The contents of all the cells of a row for each field will be used to try and create the content in the Datastore when committed. If blank cells are committed, an attempted will be made to commit them, as though they are a blank string.

Row Actions:

A row action available for this table is "remove" which will remove the row which the action is bound to within the row the action is clicked for. Row actions are on the far right of the table.

The Update Table

After the user copies a row from the Query Results table to the Update Table, the user can then make modifications to the row within the Update Table.

Unlike the Adding Table, which allows the user to make cell modifications to all cells, the "Changing Table" restricts modifications to non-primary-key fields only. Primary keys are used to uniquely identify rows to modify so they can not be modified in the Datastore without first removing and then adding them back into the Datastore.

Since the Changing Table has "original" data for each cell (not necessarily the same data as in the Datastore if the snapshotted data is stale) then any modification made to a cell in the Changing Table will show both the 'before' and 'afte'r of that cell. Any modifications to the cell that return it to its "original" value will not result in a "before and after" display for the cell and will return to a non-modified state.

In the special scenario where the user modified a cell that did not load data (because in the Query Results table the field was removed from the headers of that table before loading) then the 'before' section of the cell will display "???" as the original value. It must be noted that, regardless of the "Before" or "Original" value in the cell, committing any modified cell in the Changing Table will attempt to change the rows cell to the value in the After section without regard to the current value of the cell in the Datastore at transaction time. This means the user should be cautious when committing modifications, as the value could have changed between the time when the user loaded the data and the time when committing any modifications set in the changing table between that time could be overwritten.

Row Actions:

A row action available for this table is "Remove", which will remove the row which the action is bound to, within the row the action is clicked for. Row actions are on the far right of the table.

The Delete Table

After the user copies a row from the Query Results table to the Delete Table the user cannot make modifications to the row within the Delete Table. Technically the only fields that matter for the "Removing Table" are the primary key fields, because those are used to uniquely identify rows. Once committed, the rows in this table (based on those primary keys) will be removed.

Row Actions:

A row action available for this table is "Remove", which will remove the row which the action is bound to, within the row the action is clicked for. Row actions are on the far right of the table.